Internet Info 1994 March/Internet Info CD-ROM (Walnut Creek) (March 1994).iso/networking/mail/mime/mime.txt

Text File | 1993-02-04 | 35KB | 832 lines

                            MIME Overview

                by Mark Grand <[e-mail]>

Internet e-mail allows mail messages to be exchanged between users of
computers around the world and occasionally beyond... to space
shuttles.  One of the main reasons that Internet e-mail has achieved
such wide use is because it provides a standard mechanism for messages
to be exchanged between over 1,000,000 computers connected to the
Internet.

The standards that are the basis for Internet e-mail were established
in 1982.  Though they were state of the art in 1982, in the
intervening years they have begun to show their age.  The 1982
standards allow for mail messages that contain a single human readable
message with the restrictions that:

    * the message contains only ASCII characters.

    * the message contains no lines longer than 1000 characters.

    * the message does not exceed a certain length

The 1982 standards do not allow EDI to be transmitted through Internet
mail, since EDI messages can violate all of these restrictions.  There
are a number of other types of messages and services that have are
supported by other mail standards that have been designed more
recently.  In June of 1992 a new Internet mail standard was approved.
This new standard is called MIME.

MIME is an acronym for Multipurpose Internet Mail Extensions.  It
builds on the older standard by standardizing additional fields for
mail message headers that describe new types of content and
organization for messages.

MIME allows mail messages to contain:

    * Multiple objects in a single message.

    * Text having unlimited line length or overall length.

    * Character sets other than ASCII.

    * Multi-font messages.

    * Binary or application specific files.

    * Images, Audio, Video and multi-media messages.

MIME defines the following new header fields:

1.  A MIME-Version header field, which uses a version number to
    declare that a message conforms to the MIME standard.

2.  A Content-Type header field, which can be used to specify the type
    and subtype of data in the body of a message and to fully specify
    the encoding of such data.

    2.a.  A Text Content-Type value, which can be used to represent
          textual information in a number of character sets and
          formatted text description languages in a standardized
          manner.

    2.b.  A Multipart Content-Type value, which can be used to combine
          several body parts, possibly of differing types of data,
          into a single message.

    2.c.  An Application Content-Type value, which can be used to
          transmit application data or binary data.

    2.d.  A Message Content-Type value, for encapsulating a mail
          message.

    2.e.  An Image Content-Type value, for transmitting still image
          (picture) data.

    2.f.  An Audio Content-Type value, for transmitting audio or voice
          data.

    2.g.  A Video Content-Type value, for transmitting video or moving
          image data, possibly with audio as part of the composite
          video data format.

3.  A Content-Transfer-Encoding header field, that specifies how the
    data is encoded to allow it to pass through mail transports having
    data or character set limitations.

4.  Two optional header fields that can be used to further describe
    the data in a message body, the Content-ID and Content-Description
    header fields.

MIME is an extensible mechanism.  It is expected that the set of
content-type/subtype pairs and their associated parameters will grow
with time.  Several other MIME fields, such as character set names,
are likely to have new values defined over time.  To ensure that the
set of such values develops in an orderly, and public manner, MIME
defines a registration process which uses the Internet Assigned
Numbers Authority (IANA) as a central registry for such values.

To promote interoperability between implementations, the MIME standard
document specifies a minimal subset of the above mechanisms that are
required for an implementation to claim to conform to the MIME
standard.



                        MIME Technical Summary

MIME is defined by an Internet standard document called RFC 1341.
This document summarizes the contents of RFC 1341.  Sufficient detail
is presented here to understand the capabilities of MIME.  For
sufficient detail to implement MIME please read RFC 1341.

MIME allows messages to contain multiple objects.  When multiple
objects are in a MIME message, they are represented in a form called a
body part.  A body part has a header and a body, so it makes sense to
speak about the body of a body part. Also, body parts can be nested in
bodies that contain one or multiple body parts.

The Content-Type values, subtypes, and parameter names defined in the
MIME standard are not case insensitive.  However, many parameter
values are case sensitive.

The MIME standard is written to allow MIME to be extended in certain
ways, without having to revise the standard.  MIME specifies sets of
values that are allowed for various fields and parameters.  The
provides a procedure for extending these sets of values by registering
them with an entity called the Internet Assigned Numbers Authority
(IANA).


The MIME-Version Header Field

MIME is designed to be compatible with older Internet mail standards.
In particular, it is compatible with RFC 822.  If a mail reading
program receives a message that is a MIME message then it will likely
perform additional processing for the MIME message that it would not
perform for non-MIME messages.  In order to allow mail reading
programs to recognize MIME messages, MIME messages are required to
contain a MIME-Version header field.  The MIME-Version header field
specifies the version of the MIME standard that the message conforms
to.

As of this writing there is only version (1.0) of the MIME standard.
Messages that comply with the standard must include a header field,
with the following verbatim text:

        MIME-Version: 1.0

The MIME-Version header field is required at the top level of a
message. It is not required for each body part of a multipart entity.
It is required for the embedded headers of a body of type "message" if
and only if the embedded message is claimed to be MIME-compliant.


The Content-Type Header Field

The Content-Type field describes the data contained in the body fully
enough that the mail reader can pick an appropriate mechanism to
present the data to the user, or otherwise deal with the data in an
appropriate manner.

The Content-Type header field is used to specify the nature of data in
the body or body part, by giving type and subtype identifiers, and by
providing parameters that may be needed for certain types.  After the
type and subtype names, the remainder of the header field is a set of
parameters, specified in an attribute/value notation.  The set of
meaningful parameters differs for different types.  The order of
parameters is not significant.  Comments are allowed (in accordance
with RFC 822 rules) in structured header fields by placing them in
parentheses.

The top-level Content-Type is used to declare the general type of
data, while the subtype specifies a specific format for that type of
data.  Thus, a Content-Type of Image/xyz is enough to tell a mail
reader that the data is an image, even if the mail reader has no
knowledge of the specific image format xyz.  Such information can be
used, to decide whether or not to show a user the raw data from an
unrecognized subtype -- such an action might be reasonable for
unrecognized subtypes of Text, but not for unrecognized subtypes of
Image or Audio.  For this reason, registered subtypes of Audio, Image,
Text, and Video, should not contain embedded information that is
really of a different type.  Such compound types are usually
represented using the Multipart or Application types.

Parameters are modifiers of the content-subtype.  Although most
parameters make sense only with certain content-types, others are
"global" in the sense that they might apply to any subtype.  For
example, the Boundary parameter, which is used to indicate how body
parts are separated from each other, makes sense only for the
Multipart content-type.  The Charset parameter might make sense with
several content-types.

The MIME standard defines seven content-types.  The authors of the
MIME standard state that the set of seven types is "substantially
complete".  They expect additional supported types to be accommodated
by creating new subtypes of the seven initial top-level types.  The
MIME standard, functioning as a constitution for the MIME community,
states that new standard content types can be defined only by revising
the standard (as opposed to the registration procedure for other types
of extensions).  However, MIME does provide for the use of
non-standard content types.  Non-standard content-types can be used,
but must be given names starting with X-.  Future standard content
type names will not begin with X-.

The syntax for the content type header field is

    Content-Type := type "/" subtype [";" parameter]...

The defined content types are:

    Application
        indicates data that does not fit into any of the other
        categories, such as uninterpreted binary data or information
        to be processed by a mail-based application. In addition to
        the following subtypes, it is likely that additional subtypes
        will be defined for applications such as mail-based scheduling
        systems, spreadsheets and EDI.

    Application/Octet-Stream
        indicates uninterpreted binary data, which a mail reading
        program may simply offer to write the information into a file.
        Possible parameters for Application/Octet-Stream include:

        Name
            a suggested name for the binary data if stored as a file.

        Type
            the general type or category of binary data.  This is
            intended for human recipients rather than for automated
            processing.

        Conversions
            the operations that performed on the data before putting
            it the body.  Note that the standard defines no conversion
            values.  Any conversion values that do not begin with X-
            must be preceded by a published specification and by
            registration with IANA.

        Padding
            the number of bits of padding that were appended to the
            bitstream comprising the actual contents to produce the
            enclosed byte-oriented data.  This is useful for enclosing
            a bitstream in a body when the total number of bits is not
            a multiple of the byte size.

    Application/ODA
        indicates a body containing information encoded according to
        the Office Document Architecture (ODA) standards, using the
        ODIF representation format.  For Application/ODA, the
        Content-Type line should also specify an attribute/value pair
        that indicates the document application profile (DAP), using a
        Profile parameter.  Thus an appropriate header field might
        look like this:

            Content-Type: application/oda;
                          profile=Q112

        Consult the ODA standard for further information.

    Application/PostScript
        indicates a body containing a postscript document.

Audio
    Indicates audio data.  Audio requires an audio output device (such
    as a speaker or a telephone) to "display" the contents.

    Audio/Basic
        The content of the Audio/Basic subtype is audio encoded using
        8-bit ISDN u-law. When this subtype is present, a sample rate
        of 8000 Hz and a single channel is assumed.

    Image
        Image data.  Image requires a display device (such as a
        graphical display, a printer, or a FAX machine) to view the
        information.

    Image/Jpeg
        indicates an image in JPEG format.

    Image/Gif
        indicates an image in GIF format.

Message
    indicates an encapsulated message.

    Message/Rfc822
        indicates that the body contains an encapsulated message, with
        the syntax of an RFC 822 message.

    Message/Partial
        indicates a partial message, allowing fragmented transmission
        of bodies too large to be passed through mail transport
        facilities.  Message/Partial indicates that the body contains
        a fragment of a larger message.

        Three parameters are required in a Content-Type field of type
        Message/Partial: The first, Id, is a unique identifier, as
        close to world-unique as possible, used to match the parts
        together.  The second, Number, an integer, is the part number
        indicating where this part fits into the sequence of
        fragments.  The third, Total, another integer, is the total
        number of parts. Total is required on the final part, and
        optional on earlier parts.

    Message/External-Body
        indicates that the actual body data are not included, but
        merely referenced.  In this case, the parameters describe a
        mechanism for accessing the external data.

        When a body or body part is of type Message/External-Body,
        it consists of a header, a blank line, and the message header
        for the encapsulated message.  If another blank line appears,
        this ends the message header for the encapsulated message.
        However, since the encapsulated message's body is itself
        external, it does not appear in the area that follows.  For
        example, consider this message:

            Content-type: message/external-body;
                          access-type=local-file;
                          name=/u/nsb/Me.gif

            Content-type: image/gif

            THIS IS NOT REALLY THE BODY!

        The area at the end, which constitutes a phantom body, is
        ignored for most external-body messages.  However, it may be
        used to contain auxiliary information for a
        "mail-server".

        The only parameter of Message/External─Body that is always
        mandatory is Access-Type.  Its other parameters are mandatory
        or optional depending on the value of Access-Type.  The values
        defined for the Access-Type parameter are FTP, ANON-FTP, TFTP,
        AFS, LOCAL-FILE, and MAIL-SERVER.  Except for values beginning
        with X-, other values must be registered with IANA.

        The standard also specifies additional parameters that are to
        be used in conjunction with the various access types.

        In addition to access-type specific parameters, the standard
        defines the following parameters which are optional for all
        access types:

            * The Expiration parameter is used to specify a date after
              which the existence of the external data is not
              guaranteed.

            * The Size parameter is used to specify the size of the
              data.

Multipart

    indicates data consisting of multiple body parts; each having its
    own data type.  It is possible to tell where each body part begins
    and ends because each body part is preceded by a special string
    called an encapsulation boundary; the last body part is followed
    by a closing boundary.

    The boundary strings used are specified by a mandatory parameter
    called Boundary.  The encapsulation boundary is an end of line
    followed by two hyphens followed by the boundary parameter value
    of the Content─Type header field.  The closing boundary is the
    same as the encapsulation boundary with the addition of two
    hyphens at the end of the line.

    The encapsulation boundary must not appear inside any of the
    encapsulated parts.  It is crucial that the composing user agent
    be able to choose and specify the unique boundary that will
    separate the body parts.  Encapsulation boundaries may be no
    longer than 70 characters, not counting the blank line and leading
    hyphens.

    Thus, a typical multipart Content-Type header field might look
    like:

        Content-Type: multipart/mixed; boundary=gc0y0pkb9ex

    This indicates a body consisting of several body parts, each
    having a structure syntactically identical to an RFC 822 message,
    except that the header area may be completely empty, and each part
    is preceded by the line

        --gc0y0pkb9ex

    The closing boundary following the last body part indicates that
    no further body parts will follow.  It is identical to the
    preceding encapsulation boundaries, with the addition of two more
    hyphens at the end of the line:

        --gc0y0pkb9ex--

    There is room for additional information prior to the first
    encapsulation boundary and following the final boundary.  These
    areas are often blank.  Anything appearing before the first or
    after the last boundary is ignored.

    As a simple example, the following multipart message has two
    parts, both plain text, one explicitly typed and one implicitly
    typed:

        From: Nathaniel Borenstein <[e-mail]>
        To: Ned Freed <[e-mail]>
        Subject: Sample message
        MIME-Version: 1.0
        Content-type: multipart/mixed;
                      boundary="simple boundary"

        This is the preamble.  It is to be ignored, though it is a
        handy place for mail composers to include an explanatory note
        to non-MIME compliant readers.

        --simple boundary

        This is implicitly typed plain ASCII text.
        --simple boundary
        Content-type: text/plain; charset=us-ascii

        This is explicitly typed plain ASCII text.
        It DOES end with a line break.

        --simple boundary--
        This is the epilogue.  It is also to be ignored.

    The use of a Content-Type of multipart in a body part within
    another multipart entity is explicitly allowed.  In such cases,
    care must be taken to ensure that each nested multipart entity
    uses a different boundary delimiter.

    The use of the multipart Content-Type with only a single body part
    may be useful in certain contexts, and is explicitly permitted.

    Multipart/Mixed
        indicates multiple independent body parts to be viewed
        serially.

    Multipart/Alternative
        is syntactically identical to Multipart/Mixed.  Each part is
        an "alternative" version of the same information.  Mail
        readers should recognize that the content of the parts are
        interchangeable.  The mail reader should either choose the
        "best" type based on the user's environment and preferences,
        or offer the user the available alternatives.  Generally,
        choosing the best type means displaying only the last part
        that can be displayed.  This may be used, for example, to send
        mail in a fancy text format in such a way that it can easily
        be displayed anywhere:

            From:  Nathaniel Borenstein <[e-mail]>
            To: Ned Freed <[e-mail]>
            Subject: Formatted text mail
            MIME-Version: 1.0
            Content-Type: multipart/alternative;
                          boundary=boundary42


            --boundary42
            Content-Type: text/plain; charset=us-ascii

            ...plain text version of message goes here...
            --boundary42
            Content-Type: text/richtext

            ... richtext version of same message goes here ...
            --boundary42
            Content-Type: text/x-whatever

            ... fanciest formatted version of same message goes here
            ...
            --boundary42--

        In this example, users whose mail system understood the
        text/x-whatever format would see only the fancy version,
        while other users would see only the richtext or plain text
        version, depending on the capabilities of their system.

        Some mail reading programs that recognize more than one of the
        formats will offer the user a choice of which format to view.
        This makes sense, for example, if mail includes both a nicely
        formatted image version and an easily edited text version.
        The point is that multiple versions of the same data are not
        automatically shown.  Either the user is shown the last
        recognized version or explicitly given the choice.

    Multipart/Parallel
        is syntactically identical to Multipart/Mixed.  However, in a
        parallel body, all of the body parts are intended to be
        presented simultaneously on hardware and software that are
        capable of doing so.  Composing agents should be aware that
        many mail readers will lack this capability and will show the
        parts serially in any event.

        Multipart/Parallel will likely be used for multimedia messages
        that combine such message types as text, audio and/or video.

    Multipart/Digest
        Indicates that each of the body parts is an RFC 822 mail
        message.  Multipart/Digest is syntactically identical to
        Multipart/Mixed, except that the default Content-Type value
        for a body part is changed from Text/Plain to Message/Rfc822.

Text
    The text Content-Type is for sending material that is principally
    textual in form.  It is the default Content-Type.  A Charset
    parameter may be used to indicate the character set of the text.
    The default Content-Type for Internet mail is
        text/plain; Charset=US-ASCII.

    The value of the Charset parameter is not case sensitive.
    Allowable values are US-ASCII, ISO-8859-1, ISO-8859-2, ... and
    ISO-8859-9. The default value for Charset is US-ASCII.

    Text/Plain
        indicates plain (unformatted) text.  No special software is
        required to get the full meaning of the text, aside from
        support for the indicated character set.  Other subtypes
        should be used for enriched text in forms where application
        software may enhance the appearance of the text, but such
        software must not be required in order to get the general idea
        of the content.  Possible future subtypes include any readable
        word processor format.

    Text/Richtext
        indicates a simple portable word processing format that is
        defined by the MIME standard.  It is a very small subset of
        SGML.  Mail readers that implement Richtext may implement only
        a subset of it.

        When a mail composing program is given a file in a word
        processing format to send and there is no standardized subtype
        for that format, then the message composing program may
        reformat the file into richtext format which will preserve
        more of the original formatting information than reformatting
        the file to plain ASCII.

Video
    indicates that the body contains a time-varying-picture image,
    possibly with color and coordinated sound.  The term Video is
    used very generically and does not refer to any particular
    technology or format.  It is not meant to preclude subtypes
    such as animated drawings encoded compactly.

    Video/Mpeg
        indicates video coded according to the MPEG standard.

x-TypeName
    This is any type name that begins with X-.  A Content-Type value
    beginning with X- is a private value, to be used by consenting
    mail systems by mutual agreement.  The standard specifies no
    subtypes.

No type may be specified without a subtype.

The standard allows the use of additional sub-types without having to
change the standard.  However, it is important to insure that
sub-types used by different user communities of MIME do not conflict.
It would be confusing if Content-Type: application/foobar meant two
different things.  The standard specifies two mechanisms for defining
new Content-Type subtypes:

1.  Private values (starting with X-) may be defined between
    cooperating mail composing and reading programs without outside
    registration.  Use of this mechanism requires knowing that the
    reader of the message will not mistake the content type for
    something other than originally intended.

2.  New standard values must be registered with IANA.  Where intended
    for public use, the formats they refer to must also be defined by
    a published specification.

Messages that do not have a Content-Type field in their header are
displayed by user agents as if

    Content-Type: Text/plain; Charset=US-ASCII

had been specified.

When a mail reader encounters mail with an unknown Content-Type value,
it will generally treat it as equivalent to application/octet-stream.


The Content-Transfer-Encoding Header Field

Many Content-Types which could usefully be transported via e-mail are
represented, in their "natural" format, as 8-bit character or binary
data.  Such data cannot be transmitted over some transport protocols.
For example, SMTP (Simple Mail Transfer Protocol is an Internet
standard for transporting e-mail defined by a document called RFC 821)
restricts mail messages to 7-bit ASCII data with lines no longer than
1000 characters.

MIME provides two mechanisms for re-encoding such data into a 7-bit
short-line format.  The Content-Transfer-Encoding header field
indicates the mechanism used to perform such an encoding.  The
Content-Transfer-Encoding field indicates the transformation that has
been used to represent the body in an acceptable manner for transport.

The possible values for the Content-Transfer-Encoding field are:
        BASE64
        QUOTED-PRINTABLE
        8BIT
        7BIT
        BINARY
        x-EncodingName
These values are not case sensitive.  That is, Base64, BASE64 and
bAsE64 are all equivalent.  An encoding type of 7BIT requires that the
body is already in a 7-bit mail-ready representation.  That is the
default value: Content-Transfer-Encoding: 7BIT is assumed if the
Content-Transfer-Encoding header field is not present.

Both BASE64 and the QUOTED-PRINTABLE imply an encoding that consists
of lines no longer than 76 ASCII characters.  In other respects the
two encoding schemes are very different.

The encoding scheme implied by QUOTED-PRINTABLE is most appropriate
for data that consists primarily of printable ASCII characters. Using
this encoding method, printable ASCII character are represented as
themselves.  The equals sign (=) serves as an escape character.  Any
character that is not a printable or white space ASCII character is
represented as an equals sign followed by two hexadecimal digits.  An
equals sign in the message is also represented in this way.  Lines
that are longer than 76 characters are cut off after the 75th
character and the line ends with a equals sign.

The advantages of using the QUOTED-PRINTABLE encoding for message that
are mostly printable ASCII characters are that few additional
characters are required and the message can be read by human beings
who to not have a MIME aware mail reading program.  As an example,
here is an EDI interchange in QUOTED-PRINTABLE encoding:

ISA*00*          *00*          *01*987654321      *12*8005551234     *910=
607*0111*U*00200*110000777*0*T*>
GS*PO*987654321*8005551234*920501*2032*7721*X*002003
ST*850*000000001
BEG*00*NE*MS1112**920501**CONTRACT#
REF*IT*8128827763
N1*ST*MAVERICK SYSTEMS
N3*3312 NEW HAMPSHIRE STREET
N4*SAN JOSE*CA*94811
PO1*1*25*EA***VC*TP8MM*CB*TAPE8MM
PO1*2*30*EA***VC*TP1/4*CB*TAPE1/4INCH
PO1*3*125*EA***VC*DSK31/2*CB*DISK35
CTT*3
SE*11*000000001
GE*1*7721
IEA*1*110000777

Except for the ISA segment having been wrapped onto two lines, the
QUOTED-PRINTABLE encoding of the interchange is identical to its 7BIT
representation.

The BASE64 encoding mechanism is well suited for representing binary
files.  It represents any sequence of three bytes as four printable
ASCII characters.  The same interchange as shown above but using the
BASE64 encoding would look like:

SVNBKjAwKiAgICAgICAgICAqMDAqICAgICAgICAgICowMSo5ODc2NTQzMjEgICAgICAqMTIq
ODAwNTU1MTIzNCAgICAgKjkxMDYwNyowMTExKlUqMDAyMDAqMTEwMDAwNzc3KjAqVCo+CkdT
KlBPKjk4NzY1NDMyMSo4MDA1NTUxMjM0KjkyMDUwMSoyMDMyKjc3MjEqWCowMDIwMDMKU1Qq
ODUwKjAwMDAwMDAwMQpCRUcqMDAqTkUqTVMxMTEyKio5MjA1MDEqKkNPTlRSQUNUIwpSRUYq
SVQqODEyODgyNzc2MwpOMSpTVCpNQVZFUklDSyBTWVNURU1TCk4zKjMzMTIgTkVXIEhBTVBT
SElSRSBTVFJFRVQKTjQqU0FOIEpPU0UqQ0EqOTQ4MTEKUE8xKjEqMjUqRUEqKipWQypUUDhN
TSpDQipUQVBFOE1NClBPMSoyKjMwKkVBKioqVkMqVFAxLzQqQ0IqVEFQRTEvNElOQ0gKUE8x
KjMqMTI1KkVBKioqVkMqRFNLMzEvMipDQipESVNLMzUKQ1RUKjMKU0UqMTEqMDAwMDAwMDAx
CkdFKjEqNzcyMQpJRUEqMSoxMTAwMDA3NzcK

BASE64 bears some resemblance to uuencode in both appearance and
function.  However, uuencode uses characters that may not be processed
properly by an EBCDIC gateway.

The values 8bit, 7bit, and binary all imply that no encoding has been
performed. However, they are useful to indicate of the kind of data
contained in the object, and therefore of the kind of encoding that
might need to be performed for transmission in a given transport
system.  7bit means that the data is all represented as short lines of
ASCII data.  8bit means that the lines are short, but there may be
non-ASCII characters.  Binary means that not only may non-ASCII
characters be present, but also that the lines are not necessarily
short enough for SMTP transport.

The difference between 8bit and binary is that binary does not require
adherence to any limits on line length.  8bit and binary are intended
for compatibility with future Internet e-mail transport standards and
with gateways to non-Internet environments.  As of this writing there
are no standardized Internet e-mail transports for which it is
legitimate to include unencoded 8-bit or binary data in mail bodies.

Note that the five values defined for the Content-Transfer-Encoding
field imply nothing about the Content-Type other than the algorithm by
which it was encoded or the transport system requirements if
unencoded.

Some implementations may support additional Content-Transfer-Encoding
values (it is permitted but strongly discouraged by the standard).
Any such additional values must have names that begin with X- to
indicate its non-standard status For example:

        Content-Transfer-Encoding: x-my-new-encoding.

If a Content-Transfer-Encoding header field appears as part of a
message header, it applies to the entire body of that message.  If a
Content-Transfer-Encoding header field appears as part of a body
part's headers, it applies only to the body of that body part.  If a
message or body part is of type Multipart or Message, the
Content-Transfer-Encoding must be 7bit, 8bit or Binary.

The encoding mechanisms defined here explicitly encode all data in
ASCII.  Thus, for example, suppose a message or body part has header
fields such as:

        Content-Type: text/plain; charset=ISO-8859-1
        Content-transfer-encoding: base64

This should be interpreted to mean that the body is a Base64 ASCII
encoding of data that was originally in ISO-8859-1, and will be in
that character set again after decoding.


Optional Content-ID Header Field

It may be desirable to allow one body to reference another.
Accordingly, bodies may be labeled using the Content-ID header field,
which is syntactically identical to the RFC 822 Message-ID header
field: Content-ID values should be be as unique as possible.


Optional Content-Description Header Field

The ability to associate descriptive information with a body is often
desirable. For example, it may be useful to mark an Image body as
"a picture of the Space Shuttle Endeavor."  Such text may be
placed in the Content-Description header field.


Summary

Using MIME-Version, Content-Type, and Content-Transfer-Encoding header
fields, it is possible to include arbitrary types of data objects in
RFC 822 conformant mail messages.  No restrictions imposed by RFC 821
or RFC 822 are violated. MIME has been designed to avoid problems
caused by additional restrictions imposed by some Internet mail
transport mechanisms. The Multipart and Message content types allow
mixing and hierarchical structuring of objects of different types in a
single message.  Further content types provide a mechanism for tagging
messages or body parts as audio, image, or other kinds of data.  A
parameter syntax allows further specification of data format details,
particularly the specification of alternate character sets.
Additional optional header fields provide mechanisms for certain
extensions deemed desirable by many implementors.  Finally, a number
of useful content types are defined for general use by consenting user
agents, notably Text/Richtext, Message/Partial, and
Message/External-Body.

To promote interoperability between user agents, the MIME standard
specifies a minimal subset of MIME features a user agent must support
to be considered MIME conformant.


A Complex Multipart Example

The outline of a complex multipart message follows.  This message has
five parts to be displayed serially: two introductory plain text
parts, an embedded multipart message, a richtext part, and a closing
encapsulated text message in a non-ASCII character set.  The embedded
multipart message has two parts to be displayed in parallel, a picture
and an audio fragment.

    MIME-Version: 1.0
    From: Nathaniel Borenstein <[e-mail]>
    Subject: A multipart example
    Content-Type: multipart/mixed;
                  boundary=unique-boundary-1

    This is the preamble area of a multipart message.  Mail readers
    that understand multipart format should ignore this preamble.
    If you are reading this text, you might want to consider changing
    to a mail reader that understands how to properly display
    multipart messages.
    --unique-boundary-1

    Some text appears here...
    [Note that the preceding blank line means
    no header fields were given and this is text,
    with charset US ASCII.  It could have been
    done with explicit typing as in the next part.]

    --unique-boundary-1
    Content-type: text/plain; charset=US-ASCII

    This could have been part of the previous part, but illustrates
    explicit versus implicit typing of body parts.

    --unique-boundary-1
    Content-Type: multipart/parallel; boundary=unique-boundary-2

    --unique-boundary-2
    Content-Type: audio/basic
    Content-Transfer-Encoding: base64

    ... base64-encoded 8000 Hz single-channel
    u-law-format audio data goes here ...

    --unique-boundary-2
    Content-Type: image/gif
    Content-Transfer-Encoding: Base64

    ... base64-encoded image data goes here...

    --unique-boundary-2--

    --unique-boundary-1
    Content-type: text/richtext

    This is <bold><italic>richtext.</italic></bold><nl><nl>Isn't it
    <bigger><bigger>cool?</bigger></bigger>

    --unique-boundary-1
    Content-Type: message/rfc822

    From: (name in US-ASCII)
    Subject: (subject in US-ASCII)
    Content-Type: Text/plain; charset=ISO-8859-1
    Content-Transfer-Encoding: Quoted-printable

    ... Additional text in ISO-8859-1 goes here ...

    --unique-boundary-1--